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Abstract 


This document defines extensions to the Internet Calendaring and 
Scheduling Core Object Specification (iCalendar) (RFC 5545) to 
support use of non-Gregorian recurrence rules. It also defines how 
Calendaring Extensions to WebDAV (CalDAV) (RFC 4791) servers and 
clients can be extended to support these new recurrence rules. 
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1. Introduction 


The iCalendar [RFC5545] data format is in widespread use to represent 
calendar data. iCalendar represents dates and times using the 
Gregorian calendar system only. It does provide a way to use non- 
Gregorian calendar systems via a "CALSCALE" property, but this has 
never been used. However, there is a need to support at least non- 
Gregorian recurrence patterns to cover anniversaries, and many local, 
religious, or civil holidays based on non-Gregorian dates. 


There are several disadvantages to using the existing "CALSCALE" 
property in iCalendar for implementing non-Gregorian calendars: 


1. The "CALSCALE" property exists in the top-level "VCALENDAR" 
objects and thus applies to all components within that object. 
In today’s multi-cultural society, that restricts the ability to 
mix events from different calendar systems within the same 
iCalendar object, e.g., it would prevent having both the 
Gregorian New Year and Chinese New Year in the same iCalendar 
object. 


2. Time zone and daylight saving time rules are typically published 


using Gregorian calendar dates and rules (e.g., "the 3rd Sunday 
in March") and are thus converted to iCalendar "VTIMEZONE" 
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components using Gregorian dates and recurrence rules. This 
results in the problem whereby one component (the "VTIMEZONE") is 
fixed to the Gregorian calendar system, and another (a "VEVENT") 
wants to use a different non-Gregorian calendar scale; thus, the 
single top-level "CALSCALE" property is again inadequate. 


This specification solves these issues by allowing the "CALSCALE" to 
remain set to Gregorian but redefining the "RRULE" recurrence rule 
property to accept new items, including one that allows non-Gregorian 
calendar systems to be used. With this, all the "DATE", "DATE-TIME", 
and "PERIOD" values in the iCalendar object would remain specified 
using the Gregorian calendar system, but repeating patterns in other 


calendar systems could be defined. It is then up to calendar user 
agents and servers to map between Gregorian and non-Gregorian 
calendar systems in order to expand out recurrence instances. The 


non-Gregorian recurrence rules can be used in any iCalendar component 
that allows the "RRULE" property to be specified, including 
"VTIMEZONE" components (to allow for possible future use of non- 
Gregorian rules in published daylight saving time data). 


This specification does not itself define calendar systems; rather, 
it utilizes the calendar system registry defined by the Unicode 
Consortium in their Common Locale Data Repository (CLDR) project 
[UNICODE.CLDR], as implemented in the Unicode (International 
Components for Unicode (ICU)) Library [UNICODE.ICU]. 


This specification makes the following updates: 


It updates iCalendar [RFC5545], the XML format for iCalendar 
(xCal) [RFC6321], and the JSON format for iCalendar (jCal) 
[RFC7265], to extend the "RRULE" property definition. 


It clarifies use of the iCalendar Transport-—Independent 
Interoperability Protocol (iTIP) [RFC5546] to specify how the 
extended "RRULE" property should be handled in iTIP messages. 


It extends CalDAV [RFC4791] to specify how the extended "RRULE" 
property can be supported by CalDAV servers and clients. 


2. Conventions Used in This Document 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 


"OPTIONAL" in this document are to be interpreted as described in 
[RFC2119]. 
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The notation used in this memo is the ABNF notation of [RFC5234] as 
used by iCalendar [RFC5545]. Any syntax elements shown below that 
are not explicitly defined in this specification come from iCalendar 
[RFC5545], iTIP [RFC5546], and CalDAV [RFC4791]. 


When XML element types in the namespaces "DAV:" and 
"urn:ietf:params:xml:ns:caldav" are referenced in this document 
outside of the context of an XML fragment, the string "DAV:" and 
"CALDAV:" will be prefixed to the element type names, respectively. 


When a Gregorian calendar date is shown in text, it will use the 
format "YYYYMMDD", where "YYYY" is the 4-digit year, "MM" the 2-digit 
month, and "DD" the 2-digit day (this is the same format used in 
iCalendar [RFC5545]). The Chinese calendar will be used as an 
example of a non-Gregorian calendar for illustrative purposes. When 
a Chinese calendar date is shown in text, it will use the format 


"{C}YYYYMM[L]DD" -- i.e., the same format as Gregorian but with a 
"{C}" prefix, and an optional "L" character after the month element 
to indicate a leap month. Similarly, {E} and {H} are used in other 


examples as prefixes for Ethiopic (Amete Mihret) and Hebrew dates, 
respectively. The "{}" prefix is used for purely illustrative 
purposes and never appears in actual dates used in iCalendar or 
related specifications. Note that the Chinese calendar years shown 
in the examples are based on the Unicode (ICU) [UNICODE.ICU] 
library’s Chinese calendar epoch. While there are several different 
Chinese calendar epochs in common use, the choice of one over another 
does not impact the actual calculation of the Gregorian equivalent 
dates, provided conversion is always done using the same epoch. 


3. Overview 


In the Gregorian calendar system, each year is composed of a fixed 
number of months (12), with each month having a fixed number of days 
(between 30 and 31), except for the second month (February), which 
contains either 28 or 29 days (the latter in a leap year). Weeks are 
composed of 7 days, with day names Monday, Tuesday, Wednesday, 
Thursday, Friday, Saturday, and Sunday. Years can have either 365 or 
366 days (the latter ina leap year). The number of whole weeks ina 
year is 52 (though the [ISO.8601.2004] week numbering scheme used by 
iCalendar [RFC5545] can have a numeric count up to 53). 


In iCalendar, the "RECUR" value type defines various fields used to 
express a recurrence pattern, and those fields are given limits based 
on those of the Gregorian calendar system. Since other calendar 
systems can have different limits and other behaviors that need to be 
accounted for, the maximum values for the elements in the "RECUR" 
value are not covered by this specification. 
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To generate a set of recurring instances in a non-Gregorian calendar 
system, the following principles are used: 


1. iCalendar data continues to use the "GREGORIAN" calendar system, 
so all "DATE", "DATE-TIME", and "PERIOD" values continue to use 
the Gregorian format and limits. 


2. The "RRULE" property is extended to include an "RSCALE" element 
in its value that specifies the calendar system to use for the 
recurrence pattern. The existing elements of the "RRULE" value 
type are used, but modified to support different upper limits, 
based on the "RSCALE" value, as well as a modification to month 
numbers to allow a leap month to be specified. Existing 
requirements for the use of "RRULE" all still apply (e.g., the 
"RRULE" has to match the "DTSTART" value of the master instance). 
Other recurrence properties such as "RECURRENCE-ID", "RDATE", and 
"EXDATE" continue to use the Gregorian date format as "CALSCALE" 
is unchanged. 


When generating instances, the following procedure might be used: 


1. Convert the "DTSTART" property value of the master recurring 
component into the date and time components for the calendar 
system specified by the "RSCALE" element in the "RRULE" value. 
This provides the "seed" value for generating subsequent 
recurrence instances. 


2. Iteratively generate instances using the "RRULE" value applied to 
the year, month, and day components of the date in the new 
calendar system. 


3. For each generated instance, convert the dates and times back 
from the non-Gregorian form into Gregorian and use those values 
for other properties such as "RECURRENCE-ID". 


Consider the following example for an event representing the Chinese 
New Year: 


DTSTART; VALUE=DATE: 20130210 
RRULE : RSCALE=CHINESE; FREQ=YEARLY 
SUMMARY:Chinese New Year 


To generate instances, first the "DTSTART" value "20130210" is 
converted into the Chinese calendar system giving "{C}46500101". 
Next, the year component is incremented by one to give "{C}46510101", 
and that is then converted back into Gregorian as "20140131". 
Additional instances are generated by iteratively increasing the year 
component in the Chinese date and converting back to Gregorian. 
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4. Extended RRULE Property 


This specification extends the existing "RRULE" iCalendar property 
value to include a new "RSCALE" element that can be used to indicate 
the calendar system used for generating the recurrence pattern. 


When "RSCALE" is present, the other changes to "RRULE" are: 

1. Elements that include numeric values (e.g., "BYYEARDAY") have 
numeric ranges defined by the "RSCALE" value (i.e., in some 
calendar systems there might be more than 366 days in a year). 

2. Month numbers can include an "L" suffix to indicate that the 
specified month is a leap month in the corresponding calendar 


system (see Section 4.2). 


3. A "SKIP" element is added to define how "missing" instances are 
handled (see Section 4.1). 


The syntax for the "RECUR" value is modified in the following 
fashion: 


; recur-rule-part is extended from RFC 5545 


recur-rule-part =/ ("RSCALE" "=" rscale) 
/ ("SKIP" wow skip) 
rscale = (iana-token ; A CLDR-registered calendar system 
; name. 
/ x-name) ; A non-standard, experimental 


; calendar system name. 
; Names are case insensitive, 
; but uppercase values are preferred. 


skip = ("OMIT" / "BACKWARD" / "FORWARD") 
; Optional, with default value "OMIT", and 
; MUST NOT be present unless "RSCALE" is present. 


monthnum = 1*2DIGIT ["L"] 
; Existing element modified to include a leap 
; month indicator suffix. 


4.1. Skipping Invalid Dates 


In every calendar system, only certain combinations of day-of-month 
and month values are valid for a given year, e.g., in the Gregorian 
calendar system, January 31st is valid but February 31st is not. 
Similarly, February 29th is valid in a leap year but invalid ina 
non-leap year. Other calendar systems can also include leap months 


Daboo & Yakushev Standards Track [Page 6] 


RFC 7529 iCalendar RSCALE Extension May 2015 


(see Section 4.2), which vary from year to year. This poses a 
problem for recurring events where the frequency of recurrence might 
give rise to an invalid date. For example, a recurring event that 
starts on January 31st and is set to repeat monthly will generate 
invalid dates for months with fewer than 31 days. The iCalendar 
[RFC5545] specification requires recurrence rule generators to ignore 
any invalid dates generated when iterating the rule. However, that 
behavior might be surprising to a calendar user born on a leap day 
and whose birthday event only appears on their calendar every four 
years. There are common conventions used by humans to determine what 
to do in such cases, but those conventions can differ from calendar 
system to calendar system, as well as within the same calendar 
system, depending on the nature of the event. Typically, humans will 
expect the "missing" events to be moved to an earlier or later 
(valid) date. 


This specification introduces a new "RRULE" element, "SKIP", for use 
only when the "RSCALE" element is present. The "SKIP" element allows 
the calendar user agent to specify new options for handling invalid 
dates. 


"SKIP=OMIT": this is the default option and corresponds to the 
existing iCalendar behavior of simply ignoring the invalid date. 


"SKIP=BACKWARD": when this option is set, a date with an invalid 
month is changed to the previous (valid) month. A date with an 
invalid day-of-month is changed to the previous (valid) 
day-of-month. 


"SKIP=FORWARD": when this option is set, a date with an invalid 
month is changed to the next (valid) month. A date with an 
invalid day-of-month is changed to the next (valid) day-of-month. 


Note that for both "BACKWARD" and "FORWARD", if the month is changed 
and results in an invalid day-of-month, then the skip behavior will 
be reapplied as per the day-of-month rules, according to the 
processing order defined below. 


The month and day-of-month skip behavior is only applied at specific 

points during the processing of an "RRULE" as determined by the order 
in which any "BYxxx" elements are processed. The order is as follows 
(based on the "RRULE" element processing order defined in 

Section 3.3.10 of [RFC5545]): 

o BYMONTH 


o SKIP (for invalid month only) 
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o BYWEEKNO 


o BYYEARDAY 


o BYMONTHDAY 

o SKIP (for invalid day) 

o BYDAY 

o BYHOUR 

o BYMINUTE 

o BYSECOND 

o BYSETPOS 

o COUNT 

o UNTIL 

It is often possible to avoid having to deal with invalid dates by 
determining the real intent of a human user, e.g., a human creating a 
monthly recurring event that starts on January 31st likely intends 
the event to occur on the last day of every month, in which case that 
could be encoded into an "RRULE" by using the "BYMONTHDAY=-1" 


element. 


Only a few types of recurrence patterns are likely to need the use of 


"SKIP". The following is a list of some situations where it might be 
needed: 
1. The start date of the recurrence is a leap day in the specified 


calendar system. 


2. The start date of the recurrence is in a leap month in the 
specified calendar system. 


3. The start date of the recurrence has a day-of-month value greater 
than the smallest day-of-month value for any month in any year in 
the specified calendar system. 


4. A “BYMONTHDAY" element in an "RRULE" has a day-of-month value 


greater than the smallest day-of-month value for any month in any 
year in the specified calendar system. 
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5. A "BYMONTH" element in an "RRULE" has a value corresponding to a 
leap month in the specified calendar system. 


6. A combination of a "BYMONTHDAY" element and a "BYMONTH" element 
in an "RRULE" has a value corresponding to a leap day in the 
specified calendar system. 


7. A “BYYEARDAY" element in an "RRULE" has an absolute value greater 
than the smallest number of days in any year in the specified 
calendar system. 


8. A “BYWEEKNO" element in an "RRULE" has an absolute value greater 
than the smallest number of weeks in any year in the specified 
calendar system. 


Examples of using "SKIP" for some common use cases appear in 
Section 4.3. 


4.2. Handling Leap Months 


Leap months can occur in different calendar systems. For such 
calendar systems, the following rules are applied for "identifying" 
months: 


1. Numeric values 1 through N are used to identify regular, non- 
leap, months (where N is the number of months in a regular, non- 
leap, year). 


2. The suffix "L" is added to the regular month number to indicate a 
leap month that follows the regular month, e.g., "5L" is a leap 
month that follows the 5th regular month in the year. 


Care has to be taken when mapping the month identifiers used here 
with those of any underlying calendar system library being used. In 
particular, the Hebrew calendar system used by Unicode (ICU) 
[UNICODE.ICU] uses a month number scheme of 1 through 13, with month 
6 being the leap month, and in non-leap years, month 6 is skipped. 
Thus, ICU months 1 through 5 map to iCalendar months 1 through 5, ICU 
month 6 maps to iCalendar month "5L", and ICU months 7 through 13 map 
to iCalendar months 6 through 12. 
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4.3. Examples 
4.3.1. Chinese New Year 


Consider the following set of iCalendar properties (from the example 
above) : 


DTSTART; VALUE=DATE: 20130210 
RRULE : RSCALE=CHINESE; FREQ=YEARLY 
SUMMARY:Chinese New Year 


These define a recurring event for the Chinese New Year, with the 
first instance being the one in Gregorian year 2013. 


The Chinese date corresponding to the first instance is 
"{C}46500101". The table below shows the initial instance and the 
next four, each of which is determined by adding the appropriate 
amount to the year component of the Chinese date. Also shown is the 
conversion back to the Gregorian date: 


+-------------- E EET EEE E + 
| Chinese Date | Gregorian Date | 
E E E e shes A + 
| {C}46500101 | 20130210 - DTSTART value | 
| {C}46510101 | 20140131 

| {C}46520101 | 20150219 | 
| {C}46530101 | 20160208 | 
| {C}46540101 | 20170128 

+-------------- +-------------------------- + 


4.3.2. Ethiopic 13th Month 
Consider the following set of iCalendar properties: 


DTSTART; VALUE=DATE: 20130906 
RRULE : RSCALE=ETHIOPIC; FREQ=MONTHLY; BYMONTH=13 
SUMMARY:First day of 13th month 


These define a recurring event for the first day of the 13th month, 
with the first instance being the one in Gregorian year 2013. While 
there are a number of alternative ways of writing the "RRULE" above 
to achieve the same pattern of recurring dates, the one above was 
chosen to illustrate a "BYMONTH" value exceeding the limit of 12, 
previously described in iCalendar (Section 3.3.10 of [RFC5545]). 
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The Ethiopic date corresponding to the first instance is 
"{E}20051301". The table below shows the initial instance and the 
next four, each of which is determined by adding the appropriate 
amount to the year component of the Ethiopic date. Also shown is the 
conversion back to the Gregorian date: 


+--------------- +-------------------------- + 
| Ethiopic Date | Gregorian Date | 
A E E S ca a + 
| {E}20051301 | 20130906 - DTSTART value | 
| {E£}20061301 | 20140906 | 
| {£}20071301 | 20150906 | 
| {E}20081301 | 20160906 | 
| {E}20091301 | 20170906 | 
Sr a a E + 


Note that in this example, the value of the "BYMONTH" component in 
the "RRULE" matches the Ethiopic month value and not the Gregorian 
month. 


4.3.3. Hebrew Anniversary Starting in a Leap Month 
Consider the following set of iCalendar properties: 
DTSTART; VALUE=DATE:20140208 


RRULE : RSCALE=HEBREW; FREQ=YEARLY; BYMONTH=5L; BYMONTHDAY=8; SKIP=FORWARD 
SUMMARY :Anniversary 


These define a recurring event for the 8th day of the Hebrew month of 
Adar I (the leap month identified by "5L"), with the first instance 
being the one in Gregorian year 2014. 


The Hebrew date corresponding to the first instance is 
"{H}577405L08", which is a leap month in year 5774. The table below 
shows the initial instance and the next four, each of which is 
determined by adding the appropriate amount to the year component of 
the Hebrew date, taking into account that only year 5776 is a leap 
year. Thus, in other years the Hebrew month component is adjusted 
forward to month 6. Also shown is the conversion back to the 
Gregorian date: 
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Hrant prstan ensa A + 
| Hebrew Date | Gregorian Date | 
N A A R E + 
| {H}577405L08 | 20140208 - DTSTART value | 
| {H}57750608 | 20150227 | 
| {H}577605L08 | 20160217 | 
| {H}57770608 | 20170306 | 
| {H}57780608 | 20180223 | 
+-------------- +-------------------------- + 


4.3.4. Gregorian Leap Day with SKIP 
Consider the following set of iCalendar properties: 


DTSTART; VALUE=DATE: 20120229 
RRULE: FREQ=YEARLY 
SUMMARY: Anniversary 


These define a recurring event for the 29th of February, 2012, in the 
standard iCalendar calendar scale -- Gregorian. The standard 
iCalendar behavior is that non-existent dates in a recurrence set are 
ignored. Thus, the properties above would only generate instances in 
leap years (2016, 2020, etc.), which is likely not what users expect. 
The new "RSCALE" option defined by this specification provides the 
"SKIP" element, which can be used to "fill in" the missing instances 
in an appropriate fashion. The set of iCalendar properties below 
does that: 


DTSTART; VALUE=DATE: 20120229 
RRULE : RSCALE=GREGORIAN; FREQ=YEARLY; SKIP=FORWARD 
SUMMARY: Anniversary 


With these properties, the "missing" instances in non-leap years now 
appear on the lst of March in those years: 


4------------------------------- + 
| Instances (with SKIP=FORWARD) | Instances (without RSCALE) | 
4-------------------------- === + 
| 20120229 | 

20130301 

20140301 
| 20150301 | 
| 20160229 
| 20170301 | 
4------------------------------- + 
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3% 


Registering Calendar Systems 


This specification uses the Unicode Consortium’s registry of calendar 
systems [UNICODE.CLDR] to define valid values for the "RSCALE" 


element of an "RRULE". Note that the underscore character "_" is 
never used in CLDR-based calendar system names. New values can be 
added to this registry following Unicode Consortium rules. It is 


expected that many implementations of non-Gregorian calendars will 
use software libraries provided by Unicode (ICU) [UNICODE.ICU], and 
hence it makes sense to reuse their registry rather than creating a 
new one. "RSCALE" values are case insensitive, but uppercase is 
preferred. 


CLDR supports the use of "alias" values as alternative names for 
specific calendar systems. These alias values can be used as 
"RSCALE" values and are treated the same as the equivalent CLDR 
calendar system they are an alias for. 


When using the CLDR data, calendar agents SHOULD take into account 
the "deprecated" value and use the alternative "preferred" calendar 
system. In particular, the "islamicc" calendar system is considered 
deprecated in favor of the "islamic-civil" calendar system. 


Compatibility 


For calendar user agents that do not support the "RSCALE" element, or 
do not support the calendar system specified by the "RSCALE" element 
value, the following behaviors are possible when processing iCalendar 
data: 


1. The calendar user agent can reject the entire iCalendar object 
within which at least one iCalendar component uses the 
unrecognized "RSCALE" element or element value. 


2. The calendar user agent can reject just the iCalendar components 
containing an unrecognized "RSCALE" element or element value. 
Note that any overridden components associated with those 
rejected components MUST also be rejected (i.e., any other 
components with the same "UID" property value as the one with the 
unrecognized "RSCALE" element or element value). 


3. The calendar user agent can fall back to a non-recurring behavior 
for the iCalendar component containing the unrecognized "RSCALE" 
element or element value (effectively ignoring the "RRULE" 
property). However, any overridden components SHOULD be rejected 
as they would represent "orphaned" instances that would seem to 
be out of place. 
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In general, the best choice for a calendar user agent would be option 
(2) above, as it would be the least disruptive choice. Note that 
when processing iTIP [RFC5546] messages, the manner of the rejection 
is covered as discussed in the next section. 


7. Use with iTIP 


iTIP [RFC5546] defines how iCalendar data can be sent between 
calendar user agents to schedule calendar components between calendar 
users. It is often not possible to know the capabilities of a 
calendar user agent to which an iTIP message is being sent, but iTIP 
defines fallback behavior in such cases. 


For calendar user agents that do not support the "RSCALE" element, 
the following can occur when iTIP messages containing an "RSCALE" 
element are received: 


The receiving calendar user agent can reject the entire iTIP 
message and return an iTIP reply with a "REQUEST-STATUS" property 
set to the "3.1" status code (as per Section 3.6.14 of [RFC5546]). 


The receiving calendar user agent can fall back to a non-recurring 
behavior for the calendar component (effectively ignoring the 
"RRULE" property) and return an iTIP reply with a "REQUEST-STATUS" 


property set to the "2.3", "2.5", "2.8", or "2.10" status codes 
(as per Sections 3.6.4, 3.6.6, 3.6.9, or 3.6.11, respectively, of 
[RFC5546]). 


For calendar user agents that support the "RSCALE" element but do not 
support the calendar system specified by the "RSCALE" element value, 
the following can occur: 


The iTIP message SHOULD be rejected, returning a "REQUEST-STATUS" 
property set to the "3.1" status code (as per Section 3.6.14 of 
[RFC5546]). 


If the iTIP message is accepted and the calendar component treated 
as non-recurring, an iTIP reply with a "REQUEST-STATUS" property 
set to the "2.8" or "2.10" status codes (as per Sections 3.6.9 or 
3.6.11, respectively, of [RFC5546]) SHOULD be returned. 


As noted in Section 6, the best choice is to reject the entire iTIP 
message. 


Daboo & Yakushev Standards Track [Page 14] 


RFC 7529 iCalendar RSCALE Extension May 2015 


8. Use with xCal 
xCal [RFC6321] defines how iCalendar data is represented in XML. 
This specification extends the <recur> XML element in Section 3.6.10 


of [RFC6321] in the following manner: 


1. A new <rscale> XML element is defined as a child element of 


<recur>. The content of this element MUST be a string whose 
value is the "RSCALE" element value of the "RRULE", with case 
preserved. 


2. A new <skip> XML element is defined as a child element of 
<recur>. The content of this element MUST be a string whose 
value is the "SKIP" element value of the "RRULE", with case 
preserved. 


3. The <bymonth> XML element is redefined to support either numeric 
or string values as its content (as per Section 4.2). 


Extensions to the RELAX NG schema in Appendix A of [RFC6321] are 
defined in Appendix A of this document. 


Example: the iCalendar "RRULE" property: 


RRULE : RSCALE=GREGORIAN; FREQ=YEARLY; SKIP=FORWARD 


would be represented in XML as: 


<rrule> 
<recur> 
<rscale>GREGORIAN</rscale> 
<freq>YEARLY</freq> 
<skip>FORWARD</skip> 
</recur> 
</rrule> 


9. Use with jCal 
jCal [RFC7265] defines how iCalendar data is represented in JSON. 
This specification extends the "recur" JSON object defined in 
Section 3.6.10 of [RFC7265] in the following manner: 
1. A new "rscale" child member is defined. This MUST be a string 


whose value is the "RSCALE" element value of the "RRULE", with 
case preserved. 
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2. A new "skip" child member is defined. This MUST be a string 
whose value is the "SKIP" element value of the "RRULE", with case 


preserved. 
3. The "bymonth" child member is redefined to support either numeric 
or string values. If the "BYMONTH" element value is an integer, 


then a numeric JSON value MUST be used. If the "BYMONTH" element 
value is an integer with the "L" suffix (as per Section 4.2), 
then a JSON string value MUST be used. 

Example: the iCalendar "RRULE" property: 


RRULE : RSCALE=GREGORIAN; FREQ=YEARLY; SKIP=FORWARD 


would be represented in JSON as: 


[ 


"rrule", 

{}, 

"recur", 

{ 
"rscale": "GREGORIAN", 
"freq": "YEARLY", 
"skip": "FORWARD" 


Use with CalDAV 


The CalDAV [RFC4791] calendar access protocol allows clients and 
servers to exchange iCalendar data. In addition, CalDAV clients are 
able to query calendar data stored on the server, including time- 


based queries. Since an "RSCALE" element value determines the time 


ranges for recurring instances in a calendar component, CalDAV 
servers need to support it to interoperate with clients also using 
the "RSCALE" element. 


A CalDAV server advertises a CALDAV:supported-rscale-set Web 


Distributed Authoring and Versioning (WebDAV) property on calendar 
home or calendar collections if it supports use of the "RSCALE" 
element as described in this specification. The server can advertise 
a specific set of supported calendar systems by including one or more 
CALDAV: supported-rscale XML elements within the 

CALDAV: supported-rscale-set XML element. If no 

CALDAV: supported-rscale XML elements are included in the WebDAV 


property, then clients can try any calendar system value but need to 
be prepared for a failure when attempting to store the calendar data. 
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Clients MUST NOT attempt to store iCalendar data containing "RSCALE" 
elements if the CALDAV:supported-rscale-set WebDAV property is not 
advertised by the server. 


The server SHOULD return an HTTP 403 response with a DAV:error 
element containing a CALDAV:supported-rscale XML element, if a client 
attempts to store iCalendar data with an "RSCALE" element value not 
supported by the server. 


It is possible for an "RSCALE" value to be present in calendar data 
on the server being accessed by a client that does not support an 
"RSCALE" element or its specified value. It is expected that 
existing clients, unaware of "RSCALE", will fail gracefully by 
ignoring the calendar component, while still processing other 
calendar data on the server (as per option (2) in Section 6). 


1. CALDAV:supported-rscale-set Property 
Name: supported-rscale-set 
Namespace: urn:ietf:params:xml:ns:caldav 


Purpose: Enumerates the set of supported iCalendar "RSCALE" element 
values supported by the server. 


Protected: This property MUST be protected and SHOULD NOT be 
returned by a PROPFIND allprop request (as defined in Section 14.2 
of [RFC4918]). 


Description: See above. 
Definition: 


<!ELEMENT supported-rscale-set (supported-rscale*) > 

<!ELEMENT supported-rscale (#PCDATA) > 

<!-- PCDATA value: string - case insensitive but 
uppercase preferred --> 


Example: 


<C:supported-rscale-set 
xmilns:C="urn:ietf:params:xml:ns:caldav"> 
<C: supported-rscale>GREGORIAN</C:supported-rscale> 
<C: supported-rscale>CHINESE</C:supported-rscale> 
<C: supported-rscale>ISLAMIC-CIVIL</C:supported-rscale> 
<C: supported-rscale>HEBREW</C:supported-rscale> 
<C: supported-rscale>ETHIOPIC</C:supported-rscale> 
</C:supported-rscale-set> 
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11. Security Considerations 


This specification does not introduce any additional security 
concerns beyond those described in [RFC5545], [RFC5546], and 


[RFC4791]. 
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Appendix A. xCal RELAX NG Schema Update 


The following changes are made to the RELAX NG schema defined in 
Appendix A of [RFC6321]. 


# 3.3.10 RECUR 
# This extension adds type-rscale and type-skip, 
# and modifies type-bymonth 


value-recur = element recur { 
type-rscale?, 
type-freq, 
(type-until | type-count)?, 
element interval { 

xsd:positivelInteger 

}?, 
type-bysecond*, 
type-byminute*, 
type-byhour*, 
type-byday™*, 
type-bymonthday*, 
type-byyearday”*, 
type-byweekno*, 
type-bymonth*, 
type-bysetpos*, 
element wkst { type-weekday }?, 
type-skip? 


type-rscale = element rscale { 
xsd:string 


} 


type-bymonth = element bymonth { 
xsd: positiveInteger 
xsd:string 


} 


type-skip = element skip { 
"OMIT" | 
"BACKWARD" | 
"FORWARD" 


Daboo & Yakushev Standards Track [Page 20] 


RFC 7529 iCalendar RSCALE Extension May 2015 


Acknowledgments 


Thanks to the following for feedback: Mark Davis, Mike Douglass, 
Donald Eastlake, Peter Edberg, Marten Gajda, Philipp Kewisch, Barry 
Leiba, Jonathan Lennox, Ken Murchison, Arnaud Quillaud, Dave Thewlis, 
and Umaoka Yoshito. 


This specification originated from work at the Calendaring and 
Scheduling Consortium, which has helped with the development and 
testing of implementations. 


Authors’ Addresses 


Cyrus Daboo 

Apple Inc. 

1 Infinite Loop 
Cupertino, CA 95014 
United States 


EMail: cyrus@daboo.name 
URI: http://www.apple.com/ 


Gregory Yakushev 

Google Inc. 
Brandschenkestrasse 100 
8002 Zurich 

Switzerland 


EMail: gyakushev@yahoo.com 
URI: http://www.google.com/ 


Daboo & Yakushev Standards Track [Page 21] 


